Introducing Jockey

Two powerful, yet separate topics in computing have emerged recently: Peer-to-Peer Computing and Service Frameworks (like those implementing Web Service protocols).

Jockey is an open API for peer-to-peer and service oriented frameworks.

Why is there a need for Jockey?

As new technologies emerge, it is common for them to begin to overlap with existing technologies. It is also natural for some of the features to creep between technical domains; unfortunately this often leaves the application programmer confused. Jockey attempts to draw the line between Service Provider Frameworks and Peer Frameworks and unites the two powerful services under a single umbrella.

Jockey also acknowledges that multiple versions of peer and service frameworks exist and the number will only increase in number over time. In this vein, Jockey provides a standard interface into these services and also provides a bridging mechanism between them as well.

Audience

The Jockey API is divided into two components:

• The first component is designed for application programmers to easily work with peer and service frameworks. The application programmer will be interested in PI (Peer Interface) and SI (Service Interface).
• The second component is an API for builders of peer and service frameworks. This API allows system level people create bridges between their framework and the Jockey system. The framework builder will be interested in either the PBI (Peer Bridge Interface) or SBI (Service Bridge Interface).

Jockey Goals

• Provide a simple yet powerful API to the application programmer for working with either peer or service frameworks.
• Abstract the application programmer from the nuances in the growing number of service frameworks by providing a "factory" approach to plugging in new service frameworks.
• Abstract the application programmer from the nuances in the growing number of peer frameworks by providing a "factory" approach to plugging in new peer frameworks.
• Provide a common means for service frameworks to leverage peer networks.
• Provide a common means for peer networks to convert messages into service invocations on service frameworks.
• Provide the capability for a framework programmer to build bridges between peer networks.

Target Device

Jockey does not prescribe to the "one-size-fits-all" mentality of computing. The Jockey API is designed for desktop computers and servers. It is not intended to work on limited configuration devices. We do not believe that the Jockey is overly heavy, but the design goal remains desktop computers.

Calls made from Jockey to lightweight devices will use well-known protocols (like JXTA and SOAP) as a communication mechanism. There is NO requirement that Jockey be used on both sides of the communication link. Jockey should be used as a convenience layer on devices that have the luxury of using a convenience layer.

Initial Verification

Only time will tell if Jockey fulfills the goals that we have set out to achieve. To help prove these goals, our intent is to use the following tests as verification:

• The API provides the necessary semantics to connect to both the JXTA platform and to Gnutella.
• The service interface provides a robust method for connecting to the Apache SOAP server.
• A web service can correctly invoke another web service over the JXTA network with one or more firewalls in between the nodes. A response is sent back to the initial web service.
• A distributed "Hello World" application (both client and server side) can be written in under 20 statements.

The Big Picture

"Corporate Web Services" represents the set of web services that a business makes available to their trading partners. Typically, these services concentrate on performing business-to-business transactions.

"Personal Web Services" represents the set of web services that reside and execute on an individuals local desktop. These services can be simple information providers like those found in Hailstorm (myWallet, myCalendar, myContacts, etc.). In addition, personal web services are a repository of business logic for rich-client applications. In this context, personal web services provide an abstraction between the application UI and the business logic.

Note that bi-directional communication between personal web services and corporate web services is now possible through Jockey. This allows for corporate web services to aggregate data housed at the employee's desktop as well as allowing the desktop user to query pre-aggregated information at the corporate level.

Another benefit of Jockey is the abstraction between the application and the network. Once can anticipate that several peer-networking standards will evolve from consortiums like the Peer-to-Peer Working Group, as well as from companies like Sun, IBM and Microsoft. Regardless of the network, peer applications will still need to communicate.

Some basic assumptions were built into the design of Jockey:

With these assumptions in place, our design goal was to develop a simple application programmers API to enable ad hoc, distributed computing regardless of the aforementioned challenges.

Applications should not need to be re-written if the underlying networks change. Imagine if all applications had to be significantly modified when a company changed their network from Novell to a Microsoft network. The history of computing has told us that these types of changes will occur. The answer has been simple; provide an abstraction layer. Just as sockets provided abstraction to TCP implementations or ODBC provided abstraction to databases, we are now finding it necessary to provide abstraction from our peer networks and service invocation providers.

Time and market forces will flush out the survivors in this fast changing market. Jockey provides common semantics that preserves time and money investments in distributed application development by abstracting the developer from the Darwinian process that is unfolding in peer and service technologies.

Next: What is a P2P Framework?